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This application claims express priority to U.S. Provisional Application No. 
60/TBD,TBD entitled A System and Method for Secure Third-Party Development 
and Hosting within a Financial Services Network by Badari, et al. and filed on 
January 21, 2000. 

TECHNICAL FIELD 

This invention generally relates to electronic bill presentment and payment 
(EBPP) systems and, more particularly, to system and method for secure third- 
party content development and hosting within a financial services network. 

BACKGROUND 

The concept of buying goods on "credit", or a promise for future payment, 
is not new. Today, nearly everyone in the industrial world is familiar with 
receiving bills for goods and services. Every month, like clockwork, millions of 
consumers receive bills for goods and services. For convenience, the term 
"consumer" is used throughout this document to represent both a typical person 
who consumes goods and services as well as a business that consumes goods and 
services. 

At the end of each billing cycle, a biller typically generates a bill or 
statement for each consumer account having a positive or negative account 
balance, or having transactions that yielded a zero balance. As used herein, a 
"biller" is any party that originates billing statements for goods or services 
rendered to the consumer. Examples of billers are utilities, government, 
merchants, and intermediate billing services such as banks. The printed billing 
statement is typically customized according to the biller's preferences. For 
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example, it is common for billing statements to be printed on colored paper, 
display the biller 's logo, provide a billing summary, and show itemized 
transactions. This information is organized in a custom format that is unique to 
and controlled by the biller. 

The biller also creates remittance information that associates the consumer 
account with the bill and any payment toward the bill The remittance information 
is typically in the form of a detachable stub or coupon that the consumer detaches 
from the billing statement and returns along with the payment. This remittance 
stub is also customized according to the biller's preferences. 

Recently, electronic bill presentment and payment (EBPP) systems have 
been developed to automate this process of bill delivery and payment. Companies 
such as Microsoft, Checkfree and Visa, Inc. are developing products in this space, 
the result of which heretofore has been an associated number of closed, 
proprietary EBPP systems. One such system is described in U.S. Patent No. 
5,465,206, entitled "Electronic Bill Pay System," which issued November 7, 1995 
and is assigned to Visa International. 

The Visa bill payment system permits bills to be sent by billers to 
consumers via U.S. mail or electronically via email. Unfortunately, the Visa 
system suffers from a number of drawbacks. First, the email message containing 
the bill must conform to requirements imposed by Visa. This requirement stems 
from the need to route remittance information back to the biller through the 
VisaNet® network (one of the four Automated Clearing Houses (ACH) used by 
financial institutions to clear transactions between financial institutions). Thus, 
the biller has little or no control over the format concerning how the bill is 
presented to the customer, but must instead accommodate a format compatible 
with this network. 
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Second, the Visa system is designed to support the presentment of "bills" 
from corporate billers, and would not accommodate the myriad of financial 
transactions conducted among and between consumers. Third, these prior art 
EBPP systems (e.g., Visa, Checkfree, etc.) have not be designed for 
interoperability. Currently, there is no solution available to integrate all of the 
users from these disparate EBPP systems into a common, ubiquitous network. 

These limitations are significant in a number of respects, the most notable 
of which are the cost and responsiveness of such prior art electronic financial 
systems. Moreover, the biller must provide the Visa system with a significant 
amount of information, which the consumer would likely deem to be confidential. 
Many billers do not typically wish to share this information with third parties (e.g., 
the Visa system) for fear that the confidential information may be breached, 
resulting in fraud. 

Recently, communication protocols have been introduced, i.e., the Open 
Financial Exchange (OFX) and, more recently the Internet Financial Exchange 
(IFX), as a means through which the disparate, proprietary financial networks can 
communicate with one another. While these protocols enable billers and financial 
networks to communicate among one another, it does not provide a framework 
which enables billers to develop content within the financial networks. While it is 
known that some EBPP systems enable a biller to customize the billing statement 
presented to the consumer, it does not provide the biller with unilateral control 
over the content and format of the bill. Rather, these prior art systems provide the 
billers with a "template", which the biller can populate to generate their 
"customized" bill. The problem, however, is that while the content is unique to 
the individual biller, the form is not. Quite simply, none of the prior art EBPP 
systems enable a biller to develop or host their own content, accessible on or 
through the EBPP system. 
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Thus, a system and method for secure third-party content development and 
hosting within a financial services network is required, unencumbered by the 
limitations commonly associated with prior art development and presentment 
architectures. Just such a solution is provided below. 



SUMMARY OF THE INVENTION 

This invention concerns a system and method for secure third-party content 
development and hosting within a financial services network. According to a first 
aspect of the present invention, an electronic billing statement is presented as a 
user interface to a registered user of a server, the electronic billing statement 
comprising a first component, hosted by a financial service center, to navigate the 
user UI and invoke one or more functions of the financial service center, and a 
second component, hosted by a third-party, to provide detailed billing information 
from a biller to the registered user. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The same reference numbers are used throughout the figures to reference 
like components and features. 

Fig. 1 is a diagrammatic illustration of a data network incorporating the 
teachings of the present invention; 

Figs. 2A and 2B provide alternate embodiments of a secure content 
development system incorporating the teachings of the present invention; 

Fig. 3 is a block diagram of a computer system offering the features of the 
secure development system, according to one embodiment of the invention; 
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Figs. 4A and 4B illustrate block diagrams of alternate embodiments of a 
third-party content development system, suitable for use within the data network 
of Fig. 1; 

Fig. 5 illustrates a block diagram of an example computer system suitable 
for use to develop content within the third-party content development system of 
Fig. 5; 

Fig. 6 graphically represents an example data structure to store 
authentication codes and bill data facilitating a seamless transition between the 
financial service center and the biller to present the user with requested bill detail; 

Fig. 7 is a flow chart of an example method facilitating third-party content 
development within the financial service center of Fig. 1; 

Fig. 8 graphically illustrates an example user interface provided by the 
secure development system enabling a biller to establish and manage a 
development account on the system; 

Fig. 9 graphically represents an example user interface provided by the 
secure development system enabling a biller administrator to create a development 
certification for a developer to use the secure development system; 

Fig. 10 graphically illustrates an example user interface enabling a biller to 
customize their presence on the financial service center to utilize their own custom 
developed content; 

Fig. 11 is a flow chart of an example automated validation method to 
validate the integrity of third-party developed content before it is propagated 
beyond a working directory of the secure development system; 

Fig. 12 is a flow chart of an example method for utilizing third-party 
developed and/or hosted content within the financial service center; 

Fig. 13 is an architectural representation of a financial service center 
presenting a consumer with content including a financial service center component 
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and a third-party developed and/or hosted component, according to the teachings 
of the present invention; 

Fig. 14 graphically illustrates an example bill summary page, according to 
one embodiment of the present invention; and 

Fig. 15 illustrates an example bill detail page, according to one 
embodiment of the present invention. 

DETAILED DESCRIPTION 

This invention concerns a system and method facilitating personal 
electronic financial transactions with anyone, including non-users of the system 
and methods, via an email system. In this regard, the present invention overcomes 
a number of the limitations commonly associated with the prior art including, in 
particular, the aggregation problem. It will be appreciated, from the description to 
follow, that the present invention builds upon an innovative electronic bill 
presentment and payment system first described in presently pending U.S. Patent 
Application No. 09/XXX,XXX, which is a continuation of U.S. Patent Application 
No. 08/734,518 (now USP Z,ZZZ,ZZZ), entitled Electronic Bill Presentment and 
Payment System filed on TBD by Remmington, et al., the disclosure of which 
being expressly incorporated herein by reference. In describing the present 
invention, example network architectures and associated methods will be 
described with reference to the above drawings. It is noted, however, that 
modification to the architecture and methods described herein may well be made 
without deviating from the present invention. Indeed, such alternate embodiments 
are anticipated within the scope and spirit of the present invention. 

Example System Architecture 
Example Data Network 
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Fig. 1 illustrates an example network 100 including an innovative financial 
service center 102 including a secure third-party content development system 116. 
The secure third-party development system 116 enables third-parties (e.g., billers, 
technical consultants for billers, etc.) to develop content (e.g., application server 
pages), which is provided to consumers through the innovative FSC 102. Unlike 
prior art EBPP systems, the secure third-party development system 116 provides 
billers with substantial control over the form and substance of content provided to 
consumers via the FSC 102 by allowing the billers to author and/or host a portion 
of the content provided to the consumers. 

With continued reference to Fig. 1, network 100 is comprised of a number 
of network participants including consumers 1 04(a)... (n), billers/businesses 
1 06(a)... (n), and financial institutions 1 08(a)... (n) each communicatively coupled 
to the FSC 102 via one or more networks 110 and 112. As used herein, networks 
110 and 1 12 are intended to represent a wide variety of networks and 
communication technologies. In this regard, networks 110 and 112 may well 
comprise, for example, public networks (Internet), private networks (enterprise 
wide area networks (WAN)), data networks and communication networks (public 
switched telephony network (PSTN), cellular telephony network, and the like). In 
this regard, network 100 is intended represent a composite of any number of 
networks through which participants can access and benefit from the innovative 
services of FSC 102. Due to the confidential nature of the information and 
transactions, however, security measures are taken when communicating over 
public networks. According to one embodiment, for example, when the user is 
communicating with the FSC 102 via the Internet, FSC 102 employs the well 
known secure HyperText Transfer Protocol (HTTPS). 

It will be appreciated that each of the network participants accesses and 
utilizes the resources of network 100 through a computing platform. Accordingly, 

Lee & Hayes, PLLC 7 1221001600 MSI -428US APP 



1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 



consumers 1 04(a)... (n) are depicted communicative coupled to network 100 via 
computing devices 1 14(a)... (n), respectively. Similarly, businesses 106(a)... (n) ? 
financial institutions 1 08(a)... (n), and third-party content developer 126 also 
access the resources of network 100 through one or more computing devices. For 
ease of illustration and explanation, the computing interface for billers/businesses 
106, financial institutions 108 and third-party content developer 126 have been 
omitted from Fig. 1 so as to not obscure the innovative aspects of the present 
invention. For purposes of this discussion, use of the term "consumer", "business", 
"financial institution", "user" or "network user" are each intended to represent the 
respective entity as well as a suitable computing interface. 

As used herein the computing devices used by network users are intended 
to represent a broad range of computing devices known in the art. As will be 
shown with reference to Fig. 5, a computing device, e.g., 114, does not require any 
special features or capability other than a browser to access and utilize the features 
of FSC 102. Similarly, any number of typical personal computer systems may 
well be used to develop content for publication via FSC 102 using any of a 
number of well known application server pages (ASP) development tools such as, 
for example, FrontPage 2000 offered by Microsoft Corporation of Redmond, 
Washington. In this regard, computing devices 1 14(a). . .(n) are intended to 
include, but are not limited to, personal computers, electronic kiosks, personal 
digital assistants (PDAs), wireless telephones, wireline telephones, thin-client 
terminals, and the like through which a user may interact with email system 102. 

FSC 102 is introduced in Fig. 1 as comprising the secure development 
system 116, a storage device 118 to store and maintain administrative and 
transactional information, and a consumer user interface 120. According to one 
implementation, to be described more fully below, FSC 102 is implemented using 
one or more computer systems, or data servers, which work in cooperation to 
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provide the innovative services described herein. It will be appreciated, from the 
discussion to follow, that the innovative aspects of the FSC 102 may well be 
embodied in hardware, e.g., analog or digital circuitry, or in software executed by 
one or more processor(s) of the computer system(s) to implement the described 
functions. 

As will be developed more fully below, secure third-party development 
system 116 enables a developer to write and automatically validate content for 
publication to consumers through FSC 102. According to one aspect of the 
invention, the developed content may also redirect an accessing consumer's 
browser (or other user interface executing on a computing platform) to render 
content hosted from a billers computer system(s) 106. That is, the secure third- 
party development system 116 enables billers to author and/or host their own 
content for publication through FSC 102. 

As introduced above, storage medium 118 stores and maintains 
administrative and transaction information for use by FSC 102. As will be 
described in greater detail below, the administrative information may well contain 
a plethora of information regarding the biller, consumers and their accounts, and 
third-party developers. The transactional information provides a consumer with 
bill summary information, payment information, status information and the like. 
As used herein, storage medium 1 1 8 is intended to represent any of a number of 
mass storage devices including, but not limited to, magnetic hard disk drive(s), 
optical disk drives, compact disk (CD) read-only memory (ROM) drives, digital 
versatile disk (DVD) drives, redundant array of inexpensive disk (RAID) systems, 
tape drives, and the like. Moreover, although depicted as a single database within 
a single storage device 118, it will be appreciated that FSC 102 may utilize a 
number of storage mediums 118 comprising a plurality of databases to maintain 
administrative and transactional information. 
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Consumer user interface (UI) 120 is intended to represent any of a broad 
category of means by which a consumer can access and utilize the financial 
transaction features of FSC 102. According to one embodiment, consumer UI 120 
is a web page with links that enable a registered user to access and manage 
financial accounts and conduct financial transactions with anyone (e.g., registered 
user's and non-user's alike). According to the teachings of the present invention, 
secure third-party development system 116 enables billers to create and/or host 
content presented to a consumer via the consumer UI 120. Although described 
with respect to a graphical, web based UI, it is to be appreciated that alternate UFs 
may well be utilized without deviating from the scope and spirit of the present 
invention. 

As shown, billers/businesses 1 06(a)... (n) may access (and be accessed 
from) FSC 102 via the network in any of a number of alternate means. According 
to one implementation, business 106(a) may utilize a legacy biller integration 
system (BIS) 122 to send batch billing statements to FSC 102 for presentment to 
and payment by consumers 104(a). . .(n). According to one innovative aspect of 
the invention, billers 106(a-n) incorporating the teachings of the present invention 
may utilize a "thin" batch billing schema, to be described more fully below. 
Examples of innovative EBPP systems incorporating BIS technology are provided 
in U.S. Patent Application No. 08/734,518 to Remington, et al. described above; 
U.S. Patent Application No. 08/YYY,YYY to Campbell, et al, entitled System and 
Method for Designing Responses for Electronic Billing Statements; U.S. Patent 
Application No. 08/ZZZ,ZZZ to Dent, et aL, entitled Consumer-Based System and 
Method for Managing and Paying Electronic Billing Statements; U.S. Patent No. 
08/880,125 to Campbell, et al., entitled System and Method for Designing and 
Distributing Customized Electronic Billing Statements; U.S. Patent Application 
No. 08/BBB,BBB to Heindel, et al., entitled Distributed Electronic Billing System 
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with Gateway Interfacing Biller and Service Center, and U.S. Patent Application 
No. 08/CCC,CCC to Keith, et al., entitled Parcel Manager for Distributed 
Electronic Billing System the disclosures all of which being expressly incorporated 
herein by reference. 

Example Secure Third-party Content Development Systems 
Figs 2A and 2B illustrate two embodiments of a secure third-party content 
development system 116 suitable for use within FSC 102 in accordance with 
teachings of the present invention. With respect to Fig. 2A, secure third-party 
development system 116 is shown comprising operational controller 202, content 
development interface 204, validation agent 206, network consumer interface(s) 
210, memory 212 and, optionally, applications(s) 214, operatively coupled as 
depicted. It is to be appreciated that although depicted as separate functional 
elements in a hardware paradigm, one or more of the elements may well be 
combined (e.g., content development interface 204 and validation agent 206) and 
these innovative functions may well be implemented (in whole or part) in software 
executing on computing platform. 

Third-party development of content depends heavily on the operational 
controller 202 to enable publishing of content, testing of content prior to 
production publication and overall management of a biller's presence on FSC 102. 
The operational controller 202 provides a biller administrator to manage the 
content development process on FSC 102. In this regard, operational controller 
202 establishes a biller development account locally, to manage one or more third- 
party access accounts. For each biller development account, operational controller 
202 establishes and manages one or more third-party development accounts, 
directories and access control lists (ACLs) established on content development 
interface 204 and production interface 208. In addition, the operational controller 
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202 receives client certifications (or "certs") for each third-party developer 
authorized by the biller to access secure development system 116, and maps such 
certs to ACLs on the content development interface 204 and the production 
interface 208. Moreover, once development is complete and the resulting content 
has been validated by validation agent 206, operational controller 202 receives and 
maps network address(es) associated with publication of the content (e.g., uniform 
resource locator (URL) addresses to the content web page) to a database of such 
network addresses, facilitating further testing and publication of the content. 

Content development interface 204 provides a staging environment within 
secure development interface 116 where a developer can store content under 
development. In this regard, according to one embodiment, content development 
interface 204 is comprised of a hierarchy of directories roughly denoting a stage of 
development of content stored within the directories. According to one 
embodiment, content development interface 204 includes a "working" directory, a 
"validation" directory, and a "publication" directory. The working directory is 
where content under active development is maintained. Content that is ready for 
validation testing by validation agent 206 is moved to the validation directory. 
Content that is validated by validation agent is maintained in the publication 
directory until it is moved to the production interface 208 for publication. It 
should be appreciated that operational controller 202 limits access to the content of 
any directory to only those with a valid cert to access that content, i.e., currently 
authorized third-party developers, and FSC 102 technical/administrative support. 

According to one aspect of the present invention, secure development 
system 116 includes an automated validation agent 206. It will be appreciated by 
those skilled in the art that there is a significant risk inherent in allowing third- 
parties to develop and publish content from FSC 102. A number of businesses, 
financial institutions and consumers rely on the integrity and security of the 
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system. To address the concern of unauthorized access, secure development 
system 116 relies on registered certs to identify authorized development platforms 
(computer systems) for each biller development account. To address the concern 
of rogue or error-laden content bringing down the FSC 102, secure development 
system 116 utilizes an automated validation agent 206 to analyze the content 
before it is authorized for publication from FSC 102. In this regard, validation 
agent 206 analyzes a number of attributes of the developed content to ensure it is 
safe for publication. 

Production interface 208 contains validated content created by third-party 
developers and FSC developers for testing and publication through FSC 102. In 
this regard, production interface 208 may be regarded as a file server storing and 
deploying content to consumers via one or more network consumer interface(s) 
210. As with content development interface 204, content stored on production 
interface 208 is managed in working, validation and publication directories. The 
validation directory contains content with a limited publication, e.g., for consumer 
testing. Content in the publication directory is propagated to one or more network 
consumer interface(s) 210, which provide access portals to FSC 102 for consumers 
104. According to one embodiment, consumer network interface(s) 210 are web 
servers. 

Fig. 2B illustrates an alternate embodiment of example secure third-party 
development system 116. In accordance with network diagram of Fig. 2B, secure 
development system 116 is comprised of a distributed network of servers 
implementing the features and functions described above. Accordingly, the 
reference identifiers used in Fig. 2Amap to their functional equivalent in Fig. 2B. 

Fig. 3 illustrates an example computer system suitable for use as FSC 102 
within the data network of Fig. 1 . As used herein, but for the innovative secure 
development system 116, introduced above, computer system 102 is intended to 
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represent any of a wide variety of general or special purpose computing platforms 
which implement the teachings of the present invention. It is to be appreciated 
that the following description of computer system 102 is intended to be merely 
illustrative, as computer systems of greater or lesser capability may well be 
substituted without deviating from the spirit and scope of the present invention. 

As shown, computer 102 includes one or more processors or processing 
units 132, a system memory 134, and a bus 136 that couples various system 
components including the system memory 134 to processors 132. 

The bus 136 represents one or more of any of several types of bus 
structures, including a memory bus or memory controller, a peripheral bus, an 
accelerated graphics port, and a processor or local bus using any of a variety of 
bus architectures. The system memory includes read only memory (ROM) 138 
and random access memory (RAM) 140. A basic input/output system (BIOS) 142, 
containing the basic routines that help to transfer information between elements 
within computer 102, such as during start-up, is stored in ROM 138. Computer 
102 further includes a hard disk drive 144 for reading from and writing to a hard 
disk, not shown, a magnetic disk drive 146 for reading from and writing to a 
removable magnetic disk 148, and an optical disk drive 150 for reading from or 
writing to a removable optical disk 152 such as a CD ROM, DVD ROM or other 
such optical media. The hard disk drive 144, magnetic disk drive 146, and optical 
disk drive 150 are connected to the bus 136 by a SCSI interface 154 or some other 
suitable bus interface. The drives and their associated computer-readable media 
provide nonvolatile storage of computer readable instructions, data structures, 
program modules and other data for computer 102. 

Although the exemplary environment described herein employs a hard disk 
144, a removable magnetic disk 148 and a removable optical disk 152, it should be 
appreciated by those skilled in the art that other types of computer readable media 
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which can store data that is accessible by a computer, such as magnetic cassettes, 
flash memory cards, digital video disks, random access memories (RAMs) read 
only memories (ROM), and the like, may also be used in the exemplary operating 
environment. 

A number of program modules may be stored on the hard disk 144, 
magnetic disk 148, optical disk 152, ROM 138, or RAM 140, including an 
operating system 158, one or more application programs 160 including, for 
example, the innovative secure development system 116 incorporating the 
teachings of the present invention, other program modules 162, and program data 
164 (e.g., administrative and transactional information). A user may enter 
commands and information into computer 102 through input devices such as 
keyboard 166 and pointing device 168. Other input devices (not shown) may 
include a microphone, joystick, game pad, satellite dish, scanner, or the like. 
These and other input devices are connected to the processing unit 132 through an 
interface 170 that is coupled to bus 136. A monitor 172 or other type of display 
device is also connected to the bus 136 via an interface, such as a video adapter 
174. In addition to the monitor 172, personal computers often include other 
peripheral output devices (not shown) such as speakers and printers. 

As shown, computer 102 operates in a networked environment using 
logical connections to one or more remote computers, such as a remote computer 
176. The remote computer 176 may be another personal computer, a personal 
digital assistant, a server, a router or other network device, a network "thin-client" 
PC, a peer device or other common network node, and typically includes many or 
all of the elements described above relative to computer 102, although only a 
memory storage device 178 has been illustrated in Fig. 2. 

As shown, the logical connections depicted in Fig. 2 include a local area 
network (LAN) 180 and a wide area network (WAN) 182. Such networking 
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environments are commonplace in offices, enterprise-wide computer networks, 
Intranets, and the Internet. In one embodiment, remote computer 176 executes an 
Internet Web browser program such as the "Internet Explorer" Web browser 
manufactured and distributed by Microsoft Corporation of Redmond, Washington 
to access and utilize online services. 

When used in a LAN networking environment, computer 102 is connected 
to the local network 180 through a network interface or adapter 184. When used 
in a WAN networking environment, computer 102 typically includes a modem 186 
or other means for establishing communications over the wide area network 182, 
such as the Internet. The modem 186, which may be internal or external, is 
connected to the bus 136 via a input/output (I/O) interface 156. In addition to 
network connectivity, I/O interface 156 also supports one or more printers 188. In 
a networked environment, program modules depicted relative to the personal 
computer 102, or portions thereof, may be stored in the remote memory storage 
device. It will be appreciated that the network connections shown are exemplary 
and other means of establishing a communications link between the computers 
may be used. 

Generally, the data processors of computer 102 are programmed by means 
of instructions stored at different times in the various computer-readable storage 
media of the computer. Programs and operating systems are typically distributed, 
for example, on floppy disks or CD-ROMs. From there, they are installed or 
loaded into the secondary memory of a computer. At execution, they are loaded at 
least partially into the computer's primary electronic memory. The invention 
described herein includes these and other various types of computer-readable 
storage media when such media contain instructions or programs for implementing 
the innovative steps described below in conjunction with a microprocessor or 
other data processor. The invention also includes the computer itself when 
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programmed according to the methods and techniques described below. 
Furthermore, certain sub-components of the computer may be programmed to 
perform the functions and steps described below. The invention includes such 
sub-components when they are programmed as described. In addition, the 
invention described herein includes data structures, described below, as embodied 
on various types of memory media. 

For purposes of illustration, programs and other executable program 
components such as the operating system are illustrated herein as discrete blocks, 
although it is recognized that such programs and components reside at various 
times in different storage components of the computer, and are executed by the 
data processor(s) of the computer. 
Example Content Authoring System 

Figs. 4A and 4B illustrate example content authoring systems, suitable for 
the development and publication of content through FSC 102. With reference to 
Fig. 4A, content authoring system 400 is comprised of one or more development 
platforms 402(a-n), a gateway billing integration system (BIS) 404 including a 
prep gateway BIS 406 and a production gateway BIS 408, and one or more user 
test platforms 410(a-n), operationally coupled as depicted. It will be appreciated 
that although depicted as separate functional elements according to a hardware 
paradigm, one or more elements (e.g., prep gateway BIS and production gateway 
BIS) may well be combined into a single element, and may well be comprised of 
software functions which, when executed, implement the innovative features 
described herein. 

Development platform(s) 402(a-n) represent computing systems suitably 
endowed with content development software (e.g., FrontPage 2000 introduced 
above). According to one embodiment, each development platform 402(a-n) has a 
unique cert (not shown), which must be registered and have current authoring 
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privileges in order to utilize the features of secure development system 116. 
According to one embodiment, offline development is supported wherein the 
developer downloads FSC implemented objects to development system 402 to 
develop customized content, e.g., an application server page providing 
Registration, Support, eForms, etc. Once local coding of the ASP is complete, the 
content is moved to secure development platform 1 16 from a development system 
with a current cert, to continue the validation and publication process. 

As introduced above, the gateway BIS 404 provides a means of integrating 
legacy billing systems with FSC 102, enabling billers to leverage the legacy 
billing systems and data for use with the innovative FSC 102. A detailed 
description of the BIS is provided in the above referenced co-pending applications, 
which are included herein by reference. 

The user test platforms 410(a-n) are intended to represent any of a number 
of computer systems 114 that a consumer may use to access and utilize the 
features of FSC 102. In this implementation as a test platform 410, the computer 
systems execute a test sequence designed to identify latent defects in the 
developed content. The user test platforms 410 access content located in the 
validate directory of the production interface 208 in performing this valuable 
function. Once the user test platforms 410 have satisfactorily completed their test 
sequences, the third-party developed content is promoted to the publication 
directory, and propagated to one or more web servers 210(a-n). 

Fig. 4B illustrates an alternate embodiment of example content authoring 
system 400. In accordance with network diagram of Fig. 4B, content authoring 
system 116 is comprised of a distributed network of computing systems 
implementing the features and functions described above. Accordingly, the 
reference identifiers and description associated the elements of Fig. 4A map to 
their functional equivalent in Fig. 4B. 
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Fig. 5 is a block diagram of an example computing device 402 suitable for 
use as a content authoring platform, according to one embodiment of the present 
invention. As shown, computing device 402 includes one or more processing 
unit(s) 502, a non- volatile memory device 504, a display device 506, an input 
device 508, input/output (I/O) port(s) 510, volatile system memory 512 and a 
storage device 514 including a content development application 516 (e.g., 
FrontPage 2000) which, when executed, enables a developer to generate content 
for publication via FSC 102. 

As described above, except for its interaction with secure third-party 
development system 1 16 in developing publishable content for FSC 102, computer 
system 102 is intended to represent a wide variety of computing devices known in 
the art. Similarly, the functional blocks 402-426 are each intended to represent 
any of a plurality of devices that perform these functions and, thus, need not be 
described further. 

Example Data Structure 

Fig, 6 graphically illustrates an example data structure 118 suitable for use 
with secure development system 116 and FSC 102. As shown, data structure 118 
is comprised of a number of fields including one or more of a userJD field 602, 
password information field 604, one or more financial institution account numbers 
606, one or more authentication code fields 608(a-n) ? a billing summary filename 
field 610 and a field containing a path to detailed billing information (Detail jpath) 
612. It will be appreciated that, data structures 1 18 of greater or lesser complexity 
may well be used without deviating from the spirit of the present invention. 

As used herein, the user lD field 602 and the password information field 
604 enable FSC 102 to verify the identity and authenticity of a user requesting 
access to an account. In this regard, the user lD/password combination must be 
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unique to a single individual. A number of userJQD and password criteria may be 
used to satisfy the uniqueness criteria. In one implementation, for example, a 
user's Microsoft Passport ID (email address/password combination) are used to 
uniquely identify the individual. Although not shown, the data structure 118 may 
also contain fields for additional user information such as, for example, an 
address, a telephone number, and/or additional credit history information (not 
shown). 

The financial institution account numbers 606 provide a link to the asset- 
backed accounts of a bank, brokerage, etc., that store the financial assets to cover 
the financial transactions of the user. In this regard, the financial institution (FI) 
accounts are intended to represent any of a wide variety of such accounts known in 
the art including, but not limited to, savings accounts, checking accounts, money 
market accounts, brokerage accounts and the like. In one embodiment, the email 
system 102 provides its users with an FI account (i.e., an integrated email/FI 
account), enabling users to deposit and withdraw funds from the email account 
itself. 

According to one aspect of the invention, the authentication codes 608(a-n) 
are used to provide the seamless integration of FSC 102 hosted content with 
content hosted by the biller 106, or some other third party (e.g., a technical support 
consultant). To provide automated redirection to and authentication at a billers 
site, consumer user interface 120 (authored by FSC or some third-party) is 
configured to transmit the authentication codes (or equivalents) to the billers 
computing system. According to one implementation, the authentication codes are 
supplied to FSC 102 along with summary bill information in a batch billing 
statement downloaded to FSC (according to the thin batch bill schema introduced 
above). In an alternate embodiment, the use of authentication codes is eliminated 
through the use of a dual sign-in procedure, wherein the user first signs on to the 
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FSC 102, and then must subsequently sign on to the biller' s computing system 106 
when redirected for display of detailed bill data (for example). 

The summary bill file field 610 identifies the name of a file wherein 
summary bill data for the associated account is found. According to one 
implementation, this information is provided in the batch billing statement and 
stored in a file on FSC 102. In an alternate embodiment, summary bill file field 
610 includes path information to identify a remotely located file containing the 
summary bill information. 

The detail_path field 612 identifies the path to detailed billing information. 
According to the teachings of the present invention, introduced above, the detailed 
billing information may well be hosted on a remote, third-party server (e.g., 
associated with the billers computing system 106). 

Example Operation and Implementation 

Having introduced the architectural and functional elements of the present 
invention with reference to Figs. 1-6, the operation secure third-party development 
system 116 and implementations of biller authored and/or hosted content is 
presented with reference to the remaining Figs. 7-15. 
Example Third-party Content Development 

Fig. 7 illustrates a flow chart of an example method for secure third-party 
development of FSC content, according to one embodiment of the invention. As 
shown, the method begins with block 702, wherein a biller development account is 
created on secure development system 116. More specifically, a biller 
administrator accesses ops server 202 to establish a biller development account. 
In response, ops server 202 creates development accounts, directories and updates 
access control lists (ACLs) on staging server 204 to facilitate such development. 
Before a developer can begin using the secure development system 116, however, 
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biller administrator must add the certs uniquely identifying authorized third-party 
developers to the ACLs. 

In block 704, third-party developers save developed content to appropriate 
directories in development system 116. That is, depending on the stage of 
development, a third-party content developer saves their developed content in a 
working, validation or publication directory of staging server 204. According to 
one embodiment, staging server 204 includes the working, validation and 
publication directories for each of a number of FSC supported applications such 
as, for example, Registration services, Support services, electronic Forms content, 
and the like. 

In block 706, once initial coding is completed, the developed content is 
promoted from the working directory to a validation directory to facilitate 
validation testing of the third-party developed content. As introduced above, 
secure development system 116 invokes an instance of automated validation agent 
to automatically identify errors in the third-party developed code. According to 
one embodiment, automated validation agent 206 analyzes the developed content 
for ASP errors, and other objects the execution of which could compromise FSC 
102, other billers 106, or consumers 104. 

In block 708, validation agent 206 determines whether the analyzed content 
is acceptable. If not, the third-party developer (e.g., 126) and/or associated biller 
106 is notified, and development continues to eliminate the identified errors with 
block 710. 

If, in block 708 validation agent determines that the developed content is 
acceptable, the content is propagated to a working directory for that content on the 
production server 208, which also populates one or more web server(s) with the 
content for consumer testing. Before further consumer validation testing may be 
performed, ops server 202 must be given network address(es) to map to the newly 
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developed content, block 714. In response, ops server 202 provides the network 
address information to SQL server 212, which updates its database of network 
addresses. 

In block 716, simulated consumer testing is performed by user test 
platforms 410(a-n) to identify any latent problems that a consumer might 
encounter using the third-party developed content. If problems are identified, 
block 718, the files are automatically removed from the production and web 
servers, as the debug process continues from the working directory of the staging 
204 or production 208 servers. Note, validation testing of modified content may 
be required before the developed content can be promoted to and propagated from 
the production server 208, or before additional consumer testing. 

If, in block 718, the consumer testing of the developed content failed to 
identify any errors, the developed content is promoted to the publication directory 
of the production server 208, and is ready for production status at the authorization 
of the biller administrator. According to certain implementations, additional 
manual controls may restrict production publication of newly developed third- 
party content until FSC technical/administrative staff have manually reviewed the 
content, e.g., using consumer test platforms 410. 

In block 724, upon successful development and validation of content (722), 
ops server 202 determines whether development for the associated biller is 
complete. According to one embodiment, ops server 202 will prompt biller 106 
with a question of whether to extend the authorization of biller development 
account (and associated certs). If, in block 724 ops server determines that 
development is not complete, the development process continues with block 710. 

If, in block 724, development is complete, ops server 202 disables the biller 
development account and breaks all cert mapping, block 726. According to one 
embodiment, ops server changes the password and privileges associated with the 
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biller development account, forestalling any further access by biller or associated 
third party developers. In addition, ops server 202 removes the associated certs 
from ACLs associated with the biller. 

Fig. 8 graphically illustrates an example graphical user interface (GUI), 
projected by ops server 202, facilitating management of secure development 
system 116. As shown, GUI 800 is a web page projected by an ops server 202 of 
secure development system 116 with links to invoke one or more of the functions 
discussed above. According to the illustrated example embodiment, GUI 800 
includes links to enable a biller administrator to change their ops site password 
(802), register a publishing cert (804) for a third-party developer, customize the 
site (806) with developed content (e.g., Registration services, Support services, 
Bill presentment, etc.), and to debug (validate) (808) developed content. 

Fig. 9 illustrates a GUI facilitating publication of a cert, projected to a biller 
administrator in response to selection of link 804. According to the illustrated 
embodiment, ops server 202 instructs an operating system of development 
platform 402 to project a user interface denoting the certs associated with the 
platform 402. GUI 900 allows the user to select an appropriate cert, if more than 
one is available, for use with secure development system 116. GUI 902 is 
displayed once a valid cert is provided and registered with ops server 202. 

Fig. 10 graphically illustrates a GUI 1000 enabling an authorized biller 
administrator to customize the biller 's FSC site, according to one embodiment of 
the present invention. As shown, the GUI 1000 enables a user to identify and 
enable customized registration and support content, in addition to the bill detail 
content. 

Fig. 11 illustrates a flow chart of an example method for validating third- 
party developed content, according to one embodiment of the invention. As 
shown, the method begins with invocation of validation agent 206 by a developer 
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or biller administrator, block 1102. In block 1104, validation agent 206 analyzes 
code comprising the third-party content for conflicts, ASP errors, security 
problems, etc., and makes a determination in block 1106 whether the content is 
technically error free. 

If the content contains errors, validation agent 206 generates a report 
identifying failing content files and the location and cause of the failure. In 
addition, as introduced above, validation agent 206 deletes the files from the 
validation directory of the staging server 204. 

If, in block 1106, validation agent 206 determines that the third-party 
content is free from ASP and other errors, validation agent 206 instructs the user 
that the content passed validation testing. According to one embodiment, 
validation agent will prompt the developer or biller administrator whether they 
wish to promote the validated files to the production server and propagate the files 
to the web server(s), block 1112. If so, the files are so promoted and propagated 
by validation agent. 

According to an alternate embodiment, validation agent 206 automatically 
performs file management services, promoting validated files to the production 
server for propagation and deleting the files from the validation directory. Such an 
embodiment provides for improved file management practices, lessening the 
probability that stale files are forgotten in the validation directory. 

Fig. 12 is a flow chart illustrating a method for biller authored and hosted 
content, according to one embodiment of the present invention. As shown, the 
method begins with block 1202, wherein the biller 106 creates one or more 
authentication strings associated with each bill to be submitted to FSC 102 in a 
batch billing statement. The created strings are stored locally in a billing database 
(not shown) maintained by the biller system. 
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In block 1204, the batch billing data including at least a representation of 
the authentication strings is sent to FSC 102. According to one embodiment, 
introduced above, the batch billing data adheres to a thin batch billing schema, 
wherein minimal information is provided to the FSC 102 in the batch billing 
statement, thereby reducing the amount of confidential information is transmitted 
outside biller system 106. According to one embodiment, only a biller identifier, 
summary bill data including a consumer identifier, and the authentication codes 
are sent in the thin batch billing schema. 

In block 1206, FSC 102 receives the batch billing data and populates 
transactional records in storage device 118. More specifically, with reference to 
Fig. 6, for each consumer ID/Biller ID combination, a record 614 is entered into 
data structure 118. 

In block 1208, a requesting registered user is provided with minimal bill 
detail in an FSC generated summary page. From this summary page, the 
registered user could pay the bill, completing the transaction without any further 
review of bill data. If, in block 1210, the user requests detailed bill information, 
the summary page (authored either by FSC 102, biller 106, or third-party 
developer 126 to denote biller hosted bill-detail), FSC 102 redirects the user's 
browser to billers system 102 providing the authentication codes as a means of 
authenticating the registered user's access to the requested detailed billing 
information, block 1212. According to one embodiment of the invention, the 
redirection to and authentication with the billers system is hidden from the view of 
the registered user. According to one implementation, FSC 102 provides the user 
with an indication that the requested information is being retrieved. 

If, in block 1214, billers system is unable to authenticate the registered user 
given the provided authentication strings, billers system 106 rejects the access 
request, and FSC 102 provides the user with an error message. 
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Alternatively, if billers system 106 authenticates the registered user, a 
composite billing user interface is generated comprising FSC generated content 
and biller generated content, block 1218. 

Fig. 13 provides an architectural dependency perspective on biller authored 
and biller hosted content, according to the teachings of the present invention. As 
shown, FSC 102 minimally provides navigation aids 1204, e.g., a top 
navigation/function bar and a left navigation/function bar. In the biller authored 
model, at least a subset 1202 of the content is developed by biller 106. In one 
embodiment, the content may be authored by a third-party developer but stored 
and projected by FSC 102. Alternatively, FSC 102 and billers site 106 may 
cooperatively work to provide composite content including an FSC authored and 
hosted component (1204) and a biller authored and hosted component 1202. 

Fig. 14 graphically represents an example bill summary user interface (UI) 
1400, according to one embodiment of the present invention. As shown, the UI 
includes a top navigation/function bar 1402 and a left navigation/function bar 
1404. As introduced above, these elements are authored and hosted by FSC 102. 
In addition, UI 1400 includes lower frame 1406, which includes an advertising 
banner 1408 and bill summary information 1410. According to one embodiment, 
the lower frame 1406 is authored by biller 106, but hosted from FSC 102. There 
may be a number of advantages to hosting summary pages from FSC 102. First, 
by hosting summary page UI 1400 from FSC 102, it protects the consumer (and 
the biller) from an unavailable biller computer system. That is, if the biller system 
106 goes down, a consumer would be unable to access their account with biller. If 
the information is hosted by FSC 102, if the biller computer system 106 goes 
down, the consumer can still complete payment transactions without having to 
access the billers site (e.g., to review detailed information). 
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Fig. 15 graphically illustrates an example detailed billing user interface 
1500 with an FSC-hosted component and a biller-hosted component according to 
one embodiment of the present invention. As shown, the navigation/function bars 
1402 and 1404 are hosted from FSC 102, while the detailed bill information 1502 
is hosted from billers computer system 106. 

It is to be appreciated, given the foregoing discussion, that the innovative 
secure third-party development system 116 facilitates third-party authoring and/or 
hosting of content via FSC 102. Although the invention has been described in 
language specific to structural features and/or methodological steps, it is to be 
understood that the invention defined in the appended claims is not necessarily 
limited to the specific features or steps described. Rather, the specific features and 
steps are disclosed as exemplary forms of implementing the claimed invention. 
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